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Abstract 


The U.S. National Telecommunications and Information Administration 
(NTIA) solicited a request from the Internet Corporation for Assigned 
Names and Numbers (ICANN) to propose how the NTIA should end its 
oversight of the Internet Assigned Numbers Authority (IANA) 
functions. After broad consultations, ICANN in turn created the IANA 
Stewardship Transition Coordination Group. That group solicited 
proposals for the three major IANA functions: names, numbers, and 
protocol parameters. This document contains the IETF response to 
that solicitation for protocol parameters. It was included in an 
aggregate response to the NTIA alongside those for names and 
numbering resources that are being developed by their respective 
operational communities. A reference to that response may be found 
in the introduction, and additional correspondence is included in the 
Appendix. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7979. 
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Iz 


IETF Introduction 


In March of 2014, the U.S. National Telecommunications and 
Information Administration (NTIA) announced its intent to transition 
oversight of Internet Assigned Numbers Authority (IANA) functions 
[NTIA-Announce]. In that announcement, NTIA asked the Internet 
Corporation for Assigned Names and Numbers (ICANN) to establish a 
process to deliver a proposal for transition. As part of that 
process, the IANA Stewardship Transition Coordination Group (ICG) was 
formed. The charter for the ICG can be found in Appendix A. The ICG 
in turn solicited proposals regarding post-transition arrangements 
from the names, numbers, and protocol parameters communities in order 
to put forth a proposal to the NTIA. The final request for proposal 
(RFP) can be found in Appendix B. The response from the ICG to the 
NTIA may be found at [ICG-Response]. 


While there are interactions between all of the IANA functions and 
IETF standards, this document specifically addresses the protocol 
parameters registries function. Section 1 (this section) contains an 
introduction that is sourced solely within the IETF. Section 2 
contains the questionnaire that was written by the ICG and a formal 
response by the IETF. We have quoted questions from that 
questionnaire with ">>> ", and we have prefaced answers to questions 
being asked with "IETF Response:". Note that there are small changes 
to the questions asked in order to match the RFC format. 


We note that the following text was stated as a footnote in the 
original RFP: 


In this RFP, "IANA" refers to the functions currently 
specified in the agreement between NTIA and ICANN 
[http://www.ntia.doc.gov/page/iana-functions-purchase-order] as 
well as any other functions traditionally performed by the IANA 
functions operator. SAC-067 
[https://www.icann.org/en/system/files/files/sac-—067-en. pdf] 
provides one description of the many different meanings of the 
term "IANA" and may be useful reading in addition to the 
documents constituting the agreement itself. 
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2. The Formal RFP Response 


The entire Request for Proposals, including introduction, can be 
found in Appendix B. 


>>> 

>>> 0. Proposal Type 

>>> 

>>> Identify which category of the IANA functions this 
>>> submission proposes to address: 

>>> 


IETF Response: 
Protocol Parameters 


This response states the existing practice of the IETF, and also 
represents the views of the Internet Architecture Board and the IETF. 


>>> 

>>> I. Description of Community’s Use of IANA Functions 

>>> 

>>> This section should list the specific, distinct IANA services 
>>> or activities your community relies on. For each IANA service 
>>> or activity on which your community relies, please provide the 
>>> following: 

>>> A description of the service or activity. 

>>> 


IETF Response: 


Many IETF protocols make use of commonly defined protocol parameters. 
These parameters are used by implementers, who are the primary users 
of the IETF standards and other documents. To ensure consistent 
interpretation of these parameter values by independent 
implementations, and to promote universal interoperability, these 
IETF protocol specifications define and require globally available 
registries containing the parameter values and a pointer to any 
associated documentation. The IETF uses the IANA protocol parameters 
registries to store this information in a public location. The IETF 
community presently accesses the protocol parameter registries via 
references based on the iana.org domain name, and makes use of the 
term "IANA" in the protocol parameter registry processes [RFC5226]. 


ICANN currently operates the .ARPA top level domain on behalf of the 
Internet Architecture Board (IAB). This zone is used for certain 
Internet infrastructure services that are delegated beneath it. The 
IETF considers .ARPA part of the protocol parameters registries for 
purposes of this response. 
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>>> 


>>> A description of the customer(s) of the service or activity. 
>>> 


IETF Response: 


The IANA protocol parameters registries operator maintains the 
protocol parameters registries for the IETF in conformance with all 
relevant IETF policies, in accordance with the Memorandum of 
Understanding [RFC2860] and associated supplemental agreements that 
include service level agreements (SLAs) established between the IETF 
and ICANN [MOUSUP]. 


The IETF is a global organization that produces voluntary standards, 
whose mission is to produce high quality, relevant technical and 
engineering documents that influence the way people design, use, and 
manage the Internet in such a way as to make the Internet work better 
[RFC3935]. IETF standards are published in the RFC series. The IETF 
is responsible for the key standards that are used on the Internet 
today, including IP, TCP, DNS, BGP, and HTTP, to name but a few. 


The IETF operates in an open and transparent manner [RFC6852]. The 
processes that govern the IETF are also published in the RFC series. 
The Internet Standards Process is documented in [RFC2026]. That 
document explains not only how standards are developed, but also how 
disputes about decisions are resolved. RFC 2026 has been amended a 
number of times [BCP9info]. The standards process can be amended in 
the same manner that standards are approved. That is, someone 
proposes a change by submitting a temporary document known as an 
Internet-Draft, the community discusses it, and if rough consensus 
can be found the change is approved by the Internet Engineering 
Steering Group (IESG), who also have day-to-day responsibility for 
declaring IETF consensus on technical decisions, including those that 
affect the IANA protocol parameters registries. Anyone may propose a 
change during a Last Call, and anyone may participate in the 
community discussion. 
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>>> 

>>> What registries are involved in providing the service or 
>>> activity. 

>>> 


IETF Response: 


The protocol parameters registries are the product of IETF work. 
These also include the top-level registry for the entire IP address 
space and some of its sub-registries, autonomous system number space, 
and a number of special use registries with regard to domain names. 
For more detail please refer to the documentation in the "overlaps or 
interdependencies" section. 


Administration of the protocol parameters registries is the service 
that is provided to the IETF. 


>>> 

>>> A description of any overlaps or interdependencies between your 
>>> IANA requirements and the functions required by other customer 
>>> communities. 

>>> 


IETF Response: 


In this context, the IETF considers "overlap" to be where there is in 
some way shared responsibility for a single registry across multiple 
organizations. In this sense, there is no overlap between 
organizations because responsibility for each registry is carefully 
delineated. There are, however, points of interaction between other 
organizations, and a few cases where the IETF may further define the 
scope of a registry for technical purposes. This is the case with 
both names and numbers, as described in the paragraphs below. In all 
cases, the IETF coordinates with the appropriate organizations. 


It is important to note that the IETF does not have formal 
membership. The term "the IETF" includes anyone who wishes to 
participate in the IETF, and IETF participants may also be members of 


other communities. Staff and participants from ICANN and the 
Regional Internet Registries (RIRs) regularly participate in IETF 
activities. 


o The IETF has specified a number of special use registries with 
regard to domain names. These registries require coordination 
with ICANN as the policy authority for the DNS root, including 
community groups that are responsible for ICANN policy on domain 
names such as the Generic Names Supporting Organization (GNSO) and 
the Country Code Names Supporting Organization (ccNSO). There are 
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already mechanisms in place to perform this coordination, and the 
capacity to modify those mechanisms to meet new conditions as they 
might arise. [RFC6761] 


o The IETF specifies the DNS protocol. From time to time there have 
been and will be updates to that protocol. As we make changes we 
will broadly consult the operational community about the impact of 
those changes, as we have done in the past. 


o The IETF specifies minimum requirements for root servers. 
[RFC2870] Those requirements are currently under review, in 
consultations with the root server community. 


o The routing architecture has evolved over time, and is expected to 
continue to do so. Such evolution may have an impact on 
appropriate IP address allocation strategies. If and when that 
happens, the IETF will consult and coordinate with the RIR 
community, as we have done in the past. 


o The IETF is responsible for policy relating to the entire IP 
address space and AS number space. Through the IANA protocol 
parameters registries, the IETF delegates unicast IP address and 
AS number ranges to the RIRs [RFC7020], [RFC7249]. Special address 
allocation, such as multicast and anycast addresses, often require 
coordination. Another example of IP addresses that are not 
administered by the RIR system is Unique Local Addresses (ULAs) 
[RFC4193], where local networks employ a prefix that is not 
intended to be routed on the public Internet. New special address 
allocations are added, from time to time, related to the evolution 
of the standards. In all cases, these special assignments are 
listed in the IANA protocol paramters registries. 


o The IETF maintains sub-registries for special IPv4 and IPv6 
assignments. These are specified in [RFC3307], [RFC5771], and 
[RFC6890]. The IETF coordinates such assignments with the RIRs. 


o Changes to IETF standards may have impact on operations of RIRs 
and service providers. A recent example is the extensions to BGP 
to carry the Autonomous System numbers as four-octet entities 
[RFC6793]. It is important to note that this change occurred out 
of operational necessity, and it demonstrated strong alignment 
between the RIRs and the IETF. 
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>>> II. Existing, Pre-Transition Arrangements 


>>> 

>>> This section should describe how existing IANA-related 

>>> arrangements work, prior to the transition. 

>>> 

>>> A. Policy Sources 

>>> 

>>> 

>>> This section should identify the specific source(s) of policy 
>>> which must be followed by the IANA functions operator in its 
>>> conduct of the services or activities described above. If there 
>>> are distinct sources of policy or policy development for 

>>> different IANA activities, then please describe these 

>>> separately. For each source of policy or policy development, 
>>> please provide the following: 

>>> 

>>> Which IANA service or activity (identified in Section I) is 
>>> affected. 

>>> 


IETF Response: 
The protocol parameters registries. 


>>> 

>>> A description of how policy is developed and established and 
>>> who is involved in policy development and establishment. 

>>> 


IETF Response: 


Policy for overall management of the protocol parameters registries 
is stated in [RFC6220] and [RFC5226]. The first of these documents 
explains the model for how the registries are to be operated, how 
policy is set, and how oversight takes place. RFC 5226 specifies the 
policies that specification writers may employ when they define new 
protocol registries in the "IANA Considerations" section of each 
specification. All policies at the IETF begin with a proposal in the 
form of an Internet-Draft. Anyone may submit such a proposal. If 
there is sufficient interest, a working group whose scope includes 
the proposed work may choose to adopt it, the IESG may choose to 
create a working group, or an Area Director may choose to sponsor the 
draft. In any case, anyone may comment on the proposal as it 
progresses. A proposal cannot be passed by the IESG unless it enjoys 
sufficient community support as to indicate rough consensus 
[RFC7282]. In each case, a "Last Call" is made so that there is 
notice of any proposed change to a policy or process. Anyone may 
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comment during a Last Call. For example, this process is currently 
being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis]. 


>>> 


>>> A description of how disputes about policy are resolved. 
>>> 


IETF Response: 


Most disputes are handled at the lowest level through the working 
group and rough consensus processes. Should anyone disagree with any 
action, Section 6.5 of [RFC2026] specifies a multi-level conflict 
resolution and appeals process that includes the responsible Area 
Director, the IESG, and the IAB. Should appeals be upheld, an 
appropriate remedy is applied. In the case where someone claims that 
the procedures themselves are insufficient or inadequate in some way 
to address a circumstance, one may appeal an IAB decision to the 
Internet Society Board of Trustees. 


>>> 
>>> References to documentation of policy development and dispute 


>>> resolution processes. 
>>> 


IETF Response: 


As mentioned above, [RFC2026] Section 6.5 specifies a conflict 
resolution and appeals process. [RFC2418] specifies working group 
procedures. Note that both of these documents have been amended in 
later RFCs as indicated in the [RFC-INDEX]. 


>>> 

>>> B. Oversight and Accountability 

>>> 

>>> This section should describe all the ways in which oversight is 
>>> conducted over IANA functions operator’s provision of the 

>>> services and activities listed in Section I and all the ways in 
>>> which IANA functions operator is currently held accountable for 
>>> the provision of those services. For each oversight or 

>>> accountability mechanism, please provide as many of the 

>>> following as are applicable: 

>>> 

>>> Which IANA service or activity (identified in Section I) is 

>>> affected. 

>>> 
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IETF Response: 
The protocol parameters registries. 


>>> 

>>> If not all policy sources identified in Section II.A are 
>>> affected, identify which ones are affected. 

>>> 


IETF Response: 


All policy sources relating to the protocol parameters registry are 
affected. 


>>> 

>>> A description of the entity or entities that provide oversight 
>>> or perform accountability functions, including how individuals 
>>> are selected or removed from participation in those entities. 
>>> 


IETF Response: 


The Internet Architecture Board (IAB) is an oversight body of the 
IETF whose responsibilities include, among other things, confirming 
appointment of IESG members, managing appeals as discussed above, 
management of certain domains, including .ARPA [RFC3172], and general 
architectural guidance to the broader community. The IAB must 
approve the appointment of an organization to act as IANA operator on 
behalf of the IETF. The IAB is also responsible for establishing 
liaison relationships with other organizations on behalf of the IETF. 
The IAB’s charter is to be found in [RFC2850]. 


The IAB members are selected and may be recalled through a Nominating 
Committee (NOMCOM) process, which is described in [RFC3777] and its 
updates. This process provides for selection of active members of 
the community who themselves agree upon a slate of candidates. The 
active members are chosen randomly from volunteers with a history of 
participation in the IETF, with limits regarding having too many 
active members with the same affiliation. The selection of the 
active members is performed in a manner that makes it possible for 
anyone to verify that the correct procedure was followed. The slate 
of candidates selected by the active members are sent to the Internet 
Society Board of Trustees for confirmation. In general, members are 
appointed for terms of two years. The IAB selects its own chair. 


The IAB provides oversight of the protocol parameters registries of 
the IETF, and is responsible for selecting appropriate operator (s) 
and related per-registry arrangements. Especially when relationships 
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among protocols call for it, registries are at times operated by, or 
in conjunction with, other bodies. Unless the IAB or IETF has 
concluded that special treatment is needed, the operator for 
registries is currently ICANN. 


>>> 
>>> A description of the mechanism (e.g., contract, reporting 
>>> scheme, auditing scheme, etc.). This should include a 


>>> description of the consequences of the IANA functions operator 
>>> not meeting the standards established by the mechanism, the 
>>> extent to which the output of the mechanism is transparent and 
>>> the terms under which the mechanism may change. 

>>> 


IETF Response: 


A memorandum of understanding (MoU) between ICANN and the IETF 
community has been in place since 2000. It can be found in 
[RFC2860]. The MoU defines the work to be carried out by the IANA 
functions operator for the IETF and the Internet Research Task Force 
(IRTF), a peer organization to the IETF that focuses on 

research. [RFC2014] Each year a service level agreement is negotiated 
that supplements the MoU. 


Day-to-day administration and contract management is the 
responsibility of the IETF Administrative Director (IAD). The IETF 
Administrative Oversight Committee (IAOC) oversees the IAD. The 
members of the IAOC are also the trustees of the IETF Trust, whose 
main purpose is to hold certain intellectual property for the benefit 
of the IETF as a whole. IAOC members are appointed by the Internet 
Society Board of Trustees, the IAB, the IESG, and the NOMCOM 
[RFC4071]. The IAOC works with the IANA functions operator to 
establish annual IANA performance metrics [METRICS] and operational 
procedures, and the resulting document is adopted as an supplement to 
the MoU each year [MOUSUP]. Starting from 2014, in accordance with 
these supplements, an annual audit is performed to ensure that 
protocol parameter requests are being processed according to the 
established policies. The conclusions of this audit will be 
available for anyone in the world to review. 


To date there have been no unresolvable disputes or issues between 


the IETF and the current IANA functions operator. [RFC2860] 
specifies that should a technical dispute arise, "the IANA shall seek 
and follow technical guidance exclusively from the IESG." In the 


unlikely event that a more difficult situation should arise, the IAOC 
and the IAB would engage ICANN management to address the matter. The 
MoU also provides an option for either party to terminate the 

arrangement with six months notice. Obviously such action would only 
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be undertaken after serious consideration. In that case a new IANA 
functions operator would be selected, and a new agreement with that 
operator would be established. 


>>> 

>>> Jurisdiction(s) in which the mechanism applies and the legal 
>>> basis on which the mechanism rests. 

>>> 


IETF Response 


This mechanism is global in nature. The current agreement does not 
specify a jurisdiction. 


>>>III. Proposed Post-Transition Oversight and Accountability 
>>>Arrangements 
>>> 


>>> This section should describe what changes your community is 

>>> proposing to the arrangements listed in Section II.B in light of 
>>> the transition. If your community is proposing to replace one or 
>>> more existing arrangements with new arrangements, that 

>>> replacement should be explained and all of the elements listed 
>>> in Section II.B should be described for the new 

>>> arrangements. Your community should provide its rationale and 
>>> justification for the new arrangements. 

>>> 

>>> If your community’s proposal carries any implications for 

>>> existing policy arrangements described in Section II.A, those 
>>> implications should be described here. 

>>> 

>>> If your community is not proposing changes to arrangements 

>>> listed in Section II.B, the rationale and justification for that 
>>> choice should be provided here. 

>>> 


IETF Response: 


No new organizations or structures are required. Over the years 
since the creation of ICANN, the IETF, ICANN, and IAB have together 
created a system of agreements, policies, and oversight mechanisms 
that already cover what is needed. This system has worked well 
without any operational involvement from the NTIA. 


IANA protocol parameters registry updates will continue to function 


day-to-day, as they have been doing for the last decade or more. The 
IETF community is very satisfied with the current arrangement with 
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ICANN. RFC 2860 remains in force and has served the IETF community 
very well. RFC 6220 has laid out an appropriate service description 
and requirements. 


However in the absence of the NTIA contract a few new arrangements 
may be needed in order to ensure the IETF community’s expectations 
are met. Those expectations are the following: 


o The protocol parameters registries are in the public domain. It 
is the preference of the IETF community that all relevant parties 
acknowledge that fact as part of the transition. 


o It is possible in the future that the operation of the protocol 
parameters registries may be transitioned from ICANN to subsequent 
operator(s). It is the preference of the IETF community that, as 
part of the NTIA transition, ICANN acknowledge that it will carry 
out the obligations established under C.7.3 and 1.61 of the 
current IANA functions contract between ICANN and the NTIA 
[NTIA-Contract] to achieve a smooth transition to subsequent 
operator(s), should the need arise. Furthermore, in the event of 
a transition it is the expectation of the IETF community that 
ICANN, the IETF, and subsequent operator(s) will work together to 
minimize disruption in the use the protocol parameters registries 
or other resources currently located at iana.org. 


In developing our response we have been mindful of the following 
points that the IETF community has discussed over the last year 
[ProtoParamEvol4] that have led to the following guiding principles 
for IAB efforts that impact IANA protocol parameter registries. 
These principles must be taken together; their order is not 
significant. 


1. The IETF protocol parameters registries function has been and 
continues to be capably provided by the Internet technical community. 


The strength and stability of the function and its foundation within 
the Internet technical community are both important given how 
critical protocol parameters are to the proper functioning of IETF 
protocols. 


We think the structures that sustain the protocol parameters 
registries function need to be strong enough that they can be offered 
independently by the Internet technical community, without the need 
for backing from external parties. And we believe we largely are 
there already, although the system can be strengthened further, and 
continuous improvements are being made. 
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2. The protocol parameters registries function requires openness, 
transparency, and accountability. 


Existing documentation of how the function is administered and 
overseen is good [RFC2860], [RFC6220]. Further articulation and 
clarity may be beneficial. It is important that the whole Internet 
community can understand how the function works, and that the 
processes for registering parameters and holding those who oversee 
the protocol parameters function accountable for following those 
processes are understood by all interested parties. We are committed 
to making improvements here if necessary. 


3. Any contemplated changes to the protocol parameters registries 
function should respect existing Internet community agreements. 


The protocol parameters registries function is working well. The 
existing Memorandum of Understanding in RFC 2860 defines "the 
technical work to be carried out by the Internet Assigned Numbers 
Authority on behalf of the Internet Engineering Task Force and the 
Internet Research Task Force." Any modifications to the protocol 
parameters registries function should be made using the IETF process 
to update RFC 6220 and other relevant RFCs. Put quite simply: 
evolution, not revolution. 


4. The Internet architecture requires and receives capable service 
by Internet registries. 


The stability of the Internet depends on capable provision of not 
just IETF protocol parameters, but IP numbers, domain names, and 
other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined 
protocols. Thus we expect the role of the IETF in standards 
development, architectural guidance, and allocation of certain name/ 
number parameters to continue. IP multicast addresses and special- 
use DNS names are two examples where close coordination is needed. 
The IETF will continue to coordinate with ICANN, the RIRs, and other 
parties that are mutually invested in the continued smooth operation 
of the Internet registries. We fully understand the need to work 
together. 


5. The IETF will continue management of the protocol parameter 
registry function as an integral component of the IETF standards 
process and the use of resulting protocols. 


RFC 6220 specifies the role and function of the protocol parameters 
registry, which is critical to IETF standards processes and IETF 
protocols. The IAB, on behalf of the IETF, has the responsibility to 
define and manage the relationship with the protocol registry 
operator role. This responsibility includes the selection and 
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management of the protocol parameter registry operator, as well as 
management of the parameter registration process and the guidelines 
for parameter allocation. 


6. The protocol parameters registries are provided as a public 
service. 


Directions for the creation of protocol parameters registries and the 
policies for subsequent additions and updates are specified in RFCs. 
The protocol parameters registries are available to everyone, and 
they are published in a form that allows their contents to be 
included in other works without further permission. These works 
include, but are not limited to, implementations of Internet 
protocols and their associated documentation. 


These principles will guide the IAB, IAOC, and the rest of the IETF 
community as they work with ICANN to establish future IANA 
performance metrics and operational procedures. 


>>> IV Transition Implications 


>>> 

>>> This section should describe what your community views as the 
>>> implications of the changes it proposed in Section III. These 
>>> implications may include some or all of the following, or other 
>>> implications specific to your community: 


>>> 

>>> © Description of operational requirements to achieve continuity 
>>> of service and possible new service integration throughout 
>>> the transition. 


>>> © Risks to operational continuity 
>>> © Description of any legal framework requirements in the 


>>> absence of the NTIA contract 

>>> © Description of how you have tested or evaluated the 

>>> workability of any new technical or operational methods 

>>> proposed in this document and how they compare to established 
>>> arrangements. 

>>> 


IETF Response: 


No structural changes are required for the handling of protocol 
parameters. The principles listed above will guide IAB, IAOC, and 
the rest of the IETF community as they work with ICANN to establish 
future IANA performance metrics and operational procedures, as they 
have in the past. 
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As no services are expected to change, no continuity issues are 
anticipated, and there are no new technical or operational methods 
proposed by the IETF to test. The IETF leadership, ICANN, and the 
RIRs maintain an ongoing informal dialog to spot any unforeseen 
issues that might arise as a result of other changes. 


What is necessary as part of transition is the completion of any 
supplemental agreement (s) necessary to achieve the requirements 
outlined in our response in Section III of this RFP. 


>>> 

>>> V. NTIA Requirements 

>>> 

>>> Additionally, NTIA has established that the transition proposal 
>>> must meet the following five requirements: 

>>> 


>>> "Support and enhance the multistakeholder model;" 
>>> 


IETF Response: 


Because the IETF is open to everyone, participation is open to all 
stakeholders. IETF processes outlined in Section I were used to 
develop this proposal. Those same processes have been and shall be 
used to amend governance of the protocol parameters function. As 
mentioned previously, anyone may propose amendments to those 
processes, and anyone may take part in the decision process. 


>>> 


>>> "Maintain the security, stability, and resiliency of the 
>>> Internet DNS;" 
>>> 


IETF Response: 


No changes are proposed in this document that affect the security, 
stability, and resiliency of the DNS. 


>>> 


>>> "Meet the needs and expectation of the global customers and 
>>> partners of the IANA services;" 
>>> 


IETF Response: 
Implementers and their users from around the world make use of the 


IETF standards and the associated IANA protocol parameters 
registries. The current IANA protocol parameters registries system 


Lear & Housley Informational [Page 16] 


RFC 7979 IANA ICG Response August 2016 


is meeting the needs of these global customers. This proposal 
continues to meet their needs by maintaining the existing processes 
that have served them well in the past. 


>>> 


>>> 
>>> "Maintain the openness of the Internet." 
>>> 


IETF Response: 


This proposal maintains the existing open framework that allows 
anyone to participate in the development of IETF standards, including 
the IANA protocol parameters registries policies. Further, an 
implementer anywhere in the world has full access to the protocol 
specification published in the RFC series and the protocol parameters 
registries published at iana.org. Those who require assignments in 
the IANA protocol registries will continue to have their requests 
satisfied, as specified by the existing policies for those 
registries. 


>>> 

>>> "The proposal must not replace the NTIA role with a 

>>> government-led or an inter-governmental organization solution." 
>>> 


Policy oversight is performed by the IAB, which is neither a 
government-led or an intergovernmental organization. 


>>> 

>>> VI. Community Process 

>>> 

>>> This section should describe the process your community used for 
>>> developing this proposal, including: 


>>> 

>>> o The steps that were taken to develop the proposal and to 
>>> determine consensus. 

>>> 


IETF Response: 


The IESG established the IANAPLAN working group to develop this 
response. Anyone was welcome to join the discussion and participate 
in the development of this response. An open mailing list 
(ianaplan@ietf.org) has been associated with the working group. In 
addition, IETF’s IANA practices have been discussed in the broader 
community, and all input has been welcome. Normal IETF procedures 
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[RFC2026] [RFC2418] were used to determine rough consensus. The 
chairs of the working group reviewed open issues and, after an 
internal working group last call, determined that all had been 
satisfactorily addressed, and subsequently the IESG did a formal 
IETF-wide Last Call followed by a formal review and determined that 
the document had rough consensus. 


>>> 

>>> Links to announcements, agendas, mailing lists, consultations and 
>>> meeting proceedings. 

>>> 


IETF Response: 


The following list is not exhaustive, as there have been many open 
discussions about this transition within the IETF community in the 
past few months. 


Creation of an open mailing list to discuss the transition: 
http://mailarchive.ietf.org/arch/msg/ietf-announce/ 
ztd2ed9U04qSxI-k9-0j80jJLXC 


Announcement of a public session on the transition: 
http://mailarchive.ietf.org/arch/msg/ietf-announce/ 
M5zVmFEvTbtgVyMB_fjUSW4rJ0c 


Announcement by the IESG of the intent to form a working group: 
http://mailarchive.ietf.org/arch/msg/ietf-announce/ 
QsvU9qX98G2KqgB18 jy6UfhwK Xk 


The working group discussion: 
http://www.ietf.org/mail-archive/web/ianaplan/current/ 
maillist.html 


2014-10-06 Interim Meeting Agenda, Minutes, and presentations: 
http://www.ietf.org/proceedings/interim/2014/10/06/ianaplan/ 
proceedings. html 


Working group last call: 
http://mailarchive.ietf.org/arch/msg/ianaplan/ 
EGF 9rfJxn5O0pOnRXmS20OxYKYR8k 


Agenda from IETF 91 IANAPLAN WG meeting: 
http://www.ietf.org/proceedings/91/agenda/agenda-91-ianaplan 


Minutes of IETF 91 IANAPLAN WG meeting: 
http://www.ietf.org/proceedings/91/minutes/minutes-—91-ianaplan 
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Shepherd write-up: 
http://datatracker.ietf.org/doc/draft—ietf—-ianaplan-icg-response/ 
shepherdwriteup/ 


IETF last call: 
http://mailarchive.ietf.org/arch/msg/ietf-announce/ 
i5rx6éPfjIJCRax3Lu4qZ_38P8wBg 


>>> 

>>> An assessment of the level of consensus behind your community’s 
>>> proposal, including a description of areas of contention or 

>>> disagreement. 

>>> 


IETF Response: 


This document has attained rough consensus of the IETF Working Group 
and of the IETF community as a whole, as judged first by the working 
group chairs and then by the sponsoring Area Director, and then by 
the IESG in accordance with [RFC2026] during the 18 December 2014 
IESG telechat. The IESG has approved the draft, pending insertion of 
this answer in this section and the IAB approval note. The IAB 
approved a statement for inclusion in the document on 19 December 
2014. 


Over the course of the development of the document, several 
suggestions were raised that did not enjoy sufficient support to be 
included. Two general areas of suggestion that generated much 
discussion were 


o A suggestion for a stronger statement over what terms the IAOC 
should negotiate. 


o A suggestion that "iana.org" and other associated marks be 
transferred to the IETF trust. 


At the end of the working group process, although there was not 
unanimous support for the results, the working group chairs concluded 
that rough consensus existed in the working group. The document 
shepherd’s summary of the WG consensus for this document can be found 
here: 


https://datatracker.ietf.org/doc/draft-—ietf—-ianaplan-icg-response/ 
shepherdwriteup/ 


During IETF last call, additional people voiced support for the 
document. There were several editorial comments that resulted in 
changes, as well as some discussion of more substantial comments some 
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7. 


7. 


of which resulted in text changes. There was some discussion of 
comments already discussed earlier in the process, and but no new 
objections were raised during the IETF last call. A summary of the 
last call comments can be found from here: 


http://www.ietf.org/mail-archive/web/ianaplan/current/msg01500.html 
New draft versions were prepared that took into account all the 
agreed changes from the last call. The final version was then 
approved by the IESG. 


IANA Considerations 


This memo is a response to a request for proposals. No parameter 
allocations or changes are sought. 


Security Considerations 
While the agreement, supplements, policies, and procedures around the 
IANA function have shown strong resiliency, the IETF will continue to 
work with all relevant parties to facilitate improvements while 


maintaining availability of the IANA registries. 


IAB Note 


The IAB supports the response in this document. 
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Appendix A. The Charter of the IANA Stewardship Coordination Group 
(ICG) 


Charter for the IANA Stewardship Transition Coordination Group V.10 
(August 27, 2014) 


The IANA stewardship transition coordination group (ICG) has one 
deliverable: a proposal to the U.S. Commerce Department National 
Telecommunications and Information Administration (NTIA) regarding 
the transition of NTIA’s stewardship of the IANA functions to the 
global multi-stakeholder community. The group will conduct itself 
transparently, consult with a broad range of stakeholders, and ensure 
that its proposals support the security and stability of the IANA 
functions. 


The group’s mission is to coordinate the development of a proposal 
among the communities affected by the IANA functions. The IANA 
functions are divided into three main categories: domain names, 
number resources, and other protocol parameters. The domain names 
category falls further into the country code and generic domain name 
sub-categories. While there is some overlap among all of these 
categories, each poses distinct organizational, operational and 
technical issues, and each tends to have distinct communities of 
interest and expertise. For those reasons it is best to have work on 
the three categories of IANA parameters proceed autonomously in 
parallel and be based in the respective communities. 


The IANA stewardship transition process is taking place alongside a 
parallel and related process on enhancing ICANN accountability. 
While maintaining the accountability of Internet identifier 
governance is central to both processes, this group’s scope is 
focused on the arrangements required for the continuance of IANA 
functions in an accountable and widely accepted manner after the 
expiry of the NTIA-ICANN contract. Nevertheless, the two processes 
are interrelated and interdependent and should appropriately 
coordinate their work. 


The coordination group has four main tasks: 

(i) Act as liaison to all interested parties, including the three 
"operational communities" (i.e., those with direct operational 
or service relationship with IANA; namely names, numbers, 
protocol parameters). This task consists of: 

a. Soliciting proposals from the operational communities 
b. Soliciting the input of the broad group of communities 
affected by the IANA functions 

(ii) Assess the outputs of the three operational communities for 

compatibility and interoperability 
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(iii) Assemble a complete proposal for the transition 
(iv) Information sharing and public communication 
Describing each in more detail: 
(i) Liaison 
a. Solicit proposals 


The ICG expects a plan from the country code and generic name 
communities (possibly a joint one), a plan from the numbers 
community, and a plan from the protocol parameters community. 
Members of the ICG will ensure that the communities from which they 


are drawn are working on their part of the transition plans. This 
involves informing them of requirements and schedules, tracking 
progress, and highlighting the results or remaining issues. The role 


of a coordination group member during this phase is to provide status 
updates about the progress of his or her community in developing 
their component, and to coordinate which community will develop a 
transition proposal for each area of overlap (e.g., special-use 
registry). 


While working on the development of their proposals, the operational 
communities are expected to address common requirements and issues 
relating to the transition, in as far as they affect their parts of 
the stewardship of IANA functions. 


b. Solicit broader input 

The ICG is open for input and feedback from all interested parties. 
While no set of formal requirements related to a transition proposal 
will be requested outside the operational communities, everyone’s 


input is welcome across all topics. 


The ICG expects that all interested parties get involved as early as 


possible in the relevant community processes. Input received 
directly by the ICG may be referred to the relevant community 
discussion. 


The ICG members chosen from a particular community are the official 
communication channel between the ICG and that community. 


(ii) Assessment 


When the group receives output from the communities it will discuss 
and assess their compatibility and interoperability with the 
proposals of the other communities. Each proposal should be 
submitted with a clear record of how consensus has been reached for 
the proposal in the community, and provide an analysis that shows the 
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proposal is in practice workable. The ICG should also compile the 
input it has received beyond the operational communities, and review 
the impacts of this input. 


The ICG might at some point detect problems with the component 
proposals. At that point the role of the ICG is to communicate that 
back to the relevant communities so that they (the relevant 
communities) can address the issues. It is not in the role of the 
ICG to develop proposals or to select from among competing proposals. 


(iii) Assembling and submitting a complete proposal 


The assembly effort involves taking the proposals for the different 
components and verifying that the whole fulfills the intended scope, 
meets the intended criteria, that there are no missing parts, and 
that the whole fits together. The whole also needs to include 
sufficient independent accountability mechanisms for running the IANA 
function. The ICG will then develop a draft final proposal that 
achieves rough consensus within the ICG itself. The ICG will then 
put this proposal up for public comment involving a reasonable period 
of time for reviewing the draft proposal, analyzing and preparing 
supportive or critical comments. The ICG will then review these 
comments and determine whether modifications are required. If no 
modifications are needed, and the coordination group agrees, the 
proposal will be submitted to NTIA. 


If changes are required to fix problems or to achieve broader 
support, the ICG will work with the operational communities in a 
manner similar to what was described in task (ii) above. Updates are 
subject to the same verification, review, and consensus processes as 
the initial proposals. If, in the ICG’s opinion, broad public 
support for the proposal as articulated by the NTIA is not present, 
the parts of the proposal that are not supported return to the 
liaison phase. 


(iv) Information sharing 


The ICG serves as a central clearinghouse for public information 
about the IANA stewardship transition process. Its secretariat 
maintains an independent, publicly accessible and open website, under 
its own domain, where status updates, meetings and notices are 
announced, proposals are stored, the ICG members are listed, etc. As 
the development of the transition plans will take some time, it is 
important that information about ongoing work is distributed early 
and continuously. This will enable sharing of ideas and the 
detection of potential issues. 
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Appendix B. IANA Stewardship Transition Coordination Group Request for 
Proposals 


IANA Stewardship Transition Coordination Group Request for Proposals 
8 September 2014 
Introduction 


Under the IANA Stewardship Transition Coordination Group (ICG) 
Charter, the ICG has four main tasks: 


(i) Act as liaison to all interested parties in the IANA 
stewardship transition, including the three "operational 
communities" (i.e., those with direct operational or service 
relationships with the IANA functions operator; namely names, 
numbers, protocol parameters). This task consists of: 


a. Soliciting proposals from the operational communities 
b. Soliciting the input of the broad group of communities 
affected by the IANA functions 


(ii) Assess the outputs of the three operational communities for 
compatibility and interoperability 


(iii) Assemble a complete proposal for the transition 
(iv) Information sharing and public communication 


This Request for Proposals (RFP) addresses task (i) of the ICG 
Charter. This RFP does not preclude any form of input from the 
non-operational communities. 


0. Complete Formal Responses 


The IANA Stewardship Transition Coordination Group (ICG) seeks 
complete formal responses to this RFP through processes which are to 
be convened by each of the "operational communities" of IANA (i.e., 
those with direct operational or service relationships with the IANA 
functions operator, in connection with names, numbers, or protocol 
parameters). 


Proposals should be supported by the broad range of stakeholders 
participating in the proposal development process. Proposals should 
be developed through a transparent process that is open to and 
inclusive of all stakeholders interested in participating in the 
development of the proposal. In order to help the ICG maintain its 
light coordination role, all interested and affected parties are 
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strongly encouraged to participate directly in these community 
processes. 


The following link provides information about ongoing community 
processes and how to participate in them, and that will continue to 
be updated over time: 


https://www.icann.org/en/stewardship/community 


In this RFP, "IANA" refers to the functions currently specified in 
the agreement between NTIA and ICANN 
[http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well 
as any other functions traditionally performed by the IANA functions 
operator. SAC-067 


[https://www.icann.org/en/system/files/files/sac-067-en. pdf] 
provides one description of the many different meanings of the term 
"IANA" and may be useful reading in addition to the documents 
constituting the agreement itself. 


Communities are asked to adhere to open and inclusive processes in 
developing their responses, so that all community members may fully 
participate in and observe those processes. Communities are also 
asked to actively seek out and encourage wider participation by any 
other parties with interest in their response. 


A major challenge of the ICG will be to identify and help to 
reconcile differences between submitted proposals, in order to 
produce a single plan for the transition of IANA 

stewardship. Submitted Proposals should therefore focus on those 
elements that are considered to be truly essential to the transition 
of their specific IANA functions. The target deadline for all 
complete formal responses to this RFP is 15 January 2015. 


I. Comments 


While the ICG is requesting complete formal proposals through 
processes convened by each of the operational communities, and that 
all interested parties get involved as early as possible in the 
relevant community processes, some parties may choose to provide 
comments directly to the ICG about specific aspects of particular 
proposals, about the community processes, or about the ICG’s own 
processes. Comments may be directly submitted to the ICG any time 
via email to icg-forum@icann.org. Comments will be publicly archived 
at <http://forum.icann.org/lists/icg-forum/>. 
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Commenters should be aware that ICG will direct comments received to 
the relevant operational communities if appropriate. The ICG will 
review comments received as time and resources permit and in 
accordance with the overall timeline for the transition. That is, 
comments received about specific proposals may not be reviewed until 
those proposals have been submitted to the ICG. The ICG may 
establish defined public comment periods about specific topics in 
the future, after the complete formal responses to the RFP have been 
received. 


Required Proposal Elements 


The ICG encourages each community to submit a single proposal that 
contains the elements described in this section. 


Communities are requested to describe the elements delineated in the 
sections below in as much detail possible, and according to the 
suggested format/structure, to allow the ICG to more easily 
assimilate the results. While each question is narrowly defined to 
allow for comparison between answers, respondents are encouraged to 
provide further information in explanatory sections, including 
descriptive summaries of policies/practices and associated 
references to source documents of specific policies/practices. In 
this way, the responses to the questionnaire will be useful at the 
operational level as well as to the broader stakeholder communities. 


In the interest of completeness and consistency, proposals should 
cross-reference wherever appropriate the current IANA Functions 
Contract[3] when describing existing arrangements and proposing 
changes to existing arrangements. 


0. Proposal type 
Identify which category of the IANA functions this submission 
proposes to address: 

[ ] Names [ ] Numbers [ ] Protocol Parameters 
I. Description of Community’s Use of IANA Functions 
This section should list the specific, distinct IANA functions your 
community relies on. For each IANA function on which your community 
relies, please provide the following: 

o A description of the function; 


o A description of the customer(s) of the function; 
o What registries are involved in providing the function; 
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o A description of any overlaps or interdependencies between your 
IANA requirements and the functions required by other customer 
communities. 


If your community relies on any other IANA service or activity 
beyond the scope of the IANA functions contract, you may describe 
them here. In this case please also describe how the service or 
activity should be addressed by the transition plan. 


II. Existing, Pre-Transition Arrangements 


This section should describe how existing IANA-related arrangements 
work, prior to the transition. 


[3] http://www.ntia.doc.gov/files/ntia/ 
publications/sf_26_pg_1-2-final_award_and_sacs.pdf 


A. Policy Sources 


This section should identify the specific source(s) of policy which 
must be followed by the IANA functions operator in its conduct of 
the services or activities described above. If there are distinct 
sources of policy or policy development for different IANA 
functions, then please describe these separately. For each source of 
policy or policy development, please provide the following: 


o Which IANA function (identified in Section I) are affected. 

o A description of how policy is developed and established and who 
is involved in policy development and establishment. 

o A description of how disputes about policy are resolved. 

o References to documentation of policy development and dispute 
resolution processes. 


B. Oversight and Accountability 


This section should describe all the ways in which oversight is 
conducted over the IANA functions operator’s provision of the 
services and activities listed in Section I and all the ways in 
which the IANA functions operator is currently held accountable for 
the provision of those services. For each oversight or 
accountability mechanism, please provide as many of the following as 
are applicable: 


Which IANA functions (identified in Section I) are affected. If the 
policy sources identified in Section II.A are affected, identify 
which ones are affected and explain in what way. 
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o A description of the entity or entities that provide oversight or 
perform accountability functions, including how individuals are 
selected or removed from participation in those entities. 

o A description of the mechanism (e.g., contract, reporting scheme, 
auditing scheme, etc.). This should include a description of the 
consequences of the IANA functions operator not meeting the 
standards established by the mechanism, the extent to which the 
output of the mechanism is transparent and the terms under which 
the mechanism may change. 

o Jurisdiction(s) in which the mechanism applies and the legal basis 
on which the mechanism rests. 


III. Proposed Post-Transition Oversight and Accountability 
Arrangements 


This section should describe what changes your community is 
proposing to the arrangements listed in Section II.B in light of the 
transition. If your community is proposing to replace one or more 
existing arrangements with new arrangements, that replacement should 
be explained and all of the elements listed in Section II.B should 
be described for the new arrangements. Your community should provide 
its rationale and justification for the new arrangements. 


If your community’s proposal carries any implications for the 
interface between the IANA functions and existing policy arrangements 
described in Section II.A, those implications should be described 
here. 


If your community is not proposing changes to arrangements listed in 
Section II.B, the rationale and justification for that choice should 
be provided here. 


IV. Transition Implications 


This section should describe what your community views as the 
implications of the changes it proposed in Section III. These 
implications may include some or all of the following, or other 
implications specific to your community: 


Description of operational requirements to achieve continuity of 
service and possible new service integration throughout the 
transition. 


Risks to operational continuity and how they will be addressed. 
Description of any legal framework requirements in the absence of the 
NTIA contract. Description of how you have tested or evaluated the 
workability of any new technical or operational methods proposed in 
this document and how they compare to established arrangements. 
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Description of how long the proposals in Section III are expected to 
take to complete, and any intermediate milestones that may occur 
before they are completed. 


V. NTIA Requirements 


Additionally, NTIA has established that the transition proposal must 
meet the following five requirements: 
o Support and enhance the multistakeholder model; 
o Maintain the security, stability, and resiliency of the Internet 
DNS; 
o Meet the needs and expectation of the global customers and 
partners of the IANA functions; 
o Maintain the openness of the Internet; 
o The proposal must not replace the NTIA role with a government-—led 
or an inter-governmental organization solution. 


This section should explain how your community’s proposal meets these 
requirements and how it responds to the global interest in the IANA 
functions. 


VI. Community Process 


This section should describe the process your community used for 
developing this proposal, including: 
o The steps that were taken to develop the proposal and to determine 
consensus. 
o Links to announcements, agendas, mailing lists, consultations and 
meeting proceedings. 
o An assessment of the level of consensus behind your community’s 
proposal, including a description of areas of contention or 
disagreement. 
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Appendix C. Correspondence of the IETF to the ICG 


The following messages were sent to the ICG: 


From: Jari Arkko <jari.arkko@piuha.net> 

Subject: Re: [Internal-cg] Question from the ICG 

Date: 20 Feb 2015 23:46:20 GMT+2 

To: Alissa Cooper <alissa@cooperw.in>, ICG <internal-cg@icann.org> 
Ce: Izumi Okutani <izumi@nic.ad.jp> 


Dear Alissa and the ICG, 


We refer to the question that the ICG asked the IETF community 
on 9 Feb 2015 


http://www.ietf.org/mail-archive/web/ianaplan/current/msg01610.html 


The numbers proposal sees these changes as a requirement of the 
transition and the protocols parameters proposal does not. If 
these aspects of the proposals are perceived as incompatible would 
the numbers and protocol parameters communities be willing to 
modify their proposals to reconcile them? 


VVVV NV 


We do not observe incompatibilities between the proposals from the 
numbers and protocol parameters communities. The numbers 
community expresses a preference to transfer the trademark and 
domain, while the IETF proposal does not oppose such transfer. 
This is not an incompatibility, it is something that can be 
satisfied by implementation of both number and protocol 

parameters community’s proposals, as already specified. 


To confirm this, and to determine whether the transfer 

of the trademark and domain would be acceptable, 

we consulted the community. It is the opinion of the 

IANAPLAN working group that they would support a 

decision by the IETF Trust to hold the trademark and domain 

on behalf of the Internet community. For details, see 
http://www.ietf.org/mail-archive/web/ianaplan/current/msg01659.html 


The IETF Trust also looked at this issue. The trustees decided that 
the IETF Trust would be willing to hold intellectual property rights 
relating to the IANA function, including the IANA trademark and the 
IANA.ORG domain name. For details, see 
http://www.ietf.org/mail-archive/web/ianaplan/current/msg01664.html 


In short, we find no incompatibility between the proposals and no 
need to modify the protocol parameters proposal. 
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Best Regards, 
Jari Arkko and Russ Housley on behalf of the IETF community and 
the IETF Trust 


From: Jari Arkko <jari.arkko@piuha.net> 

Subject: [Internal-cg] IETF response to the time frame inquiry 
Date: 5 Jun 2015 13:39:50 GMT+3 

To: Alissa Cooper <alissa@cooperw.in> 

Cc: ICG <internal-cg@ianacg.org> 


This is a response to a query regarding transition finalisation and 
implementation time frames, sent to the IANAPLAN working 

group list by the chairs of the IANA Transition Coordination 

Group (ICG) on May 27th. 


While I am carrying this response back to the ICG, the substance 
of this response has been discussed in the IANAPLAN working 
group and the relevant parts of IETF leadership. I believe this 
response represents the (rough) consensus opinion that 

emerged in the discussion, as well as the current state 

of IANA arrangement updates that our leadership bodies 

have been working on. 


The IETF is ready today to take the next steps in the 
implementation of the transition of the stewardship. 

In our case, most of the necessary framework is already 
in place and implemented in preceding years. 


The remaining step is an updated agreement with 
ICANN which addresses two issues. These issues are 
outlined in Section 2.III in the Internet Draft 
draft-—ietf-ianaplan-icg-response-09.txt: 


o The protocol parameters registries are in the public domain. It 
is the preference of the IETF community that all relevant parties 
acknowledge that fact as part of the transition. 


o It is possible in the future that the operation of the protocol 
parameters registries may be transitioned from ICANN to subsequent 
operator(s). It is the preference of the IETF community that, as 
part of the NTIA transition, ICANN acknowledge that it will carry 
out the obligations established under C.7.3 and 1.61 of the 
current IANA functions contract between ICANN and the NTIA 
[NTIA-Contract] to achieve a smooth transition to subsequent 
operator(s), should the need arise. Furthermore, in the event of 
a transition it is the expectation of the IETF community that 
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ICANN, the IETF, and subsequent operator(s) will work together to 
minimize disruption in the use of the protocol parameters registries 
or other resources currently located at iana.org. 


The IETF Administrative Oversight Committee (IAOC) has 

decided to use an update of our yearly IETF-ICANN Service Level 
Agreement (SLA) as the mechanism for this updated 

agreement. They have drafted the update and from our 
perspective it could be immediately executed. Once the updated 
agreement is in place, the transition would be substantially 
complete, with only the NTIA contract lapse or termination 

as a final step. 


Of course, we are not alone in this process. Interactions 
with other parts of the process may bring additional 

tasks that need to be executed either before or 

after the transition. First, the ICG, the RIRs, 

and IETF have discussed the possibility of aligning 

the treatment of IANA trademarks and domains. The 

IETF Trust has signalled that it would be willing to do this, 
if asked. We are awaiting coordination on this 

to complete, but see no problem in speedy 


execution once the decision is made. From our 
perspective this is not a prerequisite for the transition, 
however. 


In addition, the names community has proposed the 

creation of a ’Post Transition IANA’ (PTI). If the existing 
agreements between the IETF and ICANN remain in place 

and the SLAs discussed above are not affected, the IETF 
transition would take place as described above. That is 

our preference. If the final details of the PTI plan require 
further action from the IETF, more work and community 
agreement would be required. The timeline for that work 
cannot be set until the scope is known. 


Jari Arkko, IETF Chair 
(reporting his summary of the situation) 


From: Jari Arkko <jari.arkko@piuha.net> 

Subject: [Internal-cg] Response from IETF IANAPLAN WG regarding the 
ICG question on coordination 

Date: 8 Oct 2015 10:13:07 GMT+3 

To: IANA etc etc Coordination Group <internal-cg@ianacg.org> 


The IANAPLAN working group has discussed the coordination 
question from the ICG. In the working group’s opinion, 
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informal coordination exists today and will continue, which 
is consistent with the commitment requested by the ICG. 


This is also consistent with an overall coordination commitment 
already indicated in the IANAPLAN proposal. The proposal 
is a consensus document of the IETF. From the proposal: 


The IETF will continue to coordinate with ICANN, the RIRs, and other 
parties that are mutually invested in the continued smooth operation 
of the Internet registries. 


The coordination approach is also consistent with the 

comments that were sent by the IAB to the ICG during the 

public comment period. See 
https://www.iab.org/documents/correspondence-reports-—documents/2015- 
2/iab-comments-on-icg-proposal/. 


Jari Arkko, 
IETF Chair and the Area Director for the IANAPLAN WG 
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